Copyright: DumpAcl Copyright ® 1994 Somar Software


DumpAcl Help Contents
Somar DumpAcl (TM) Version 2.0 Help Contents

Copyright © 1994 Somar Software

Overview

Installation

Uninstallation

Known bugs, limitations and planned enhancements

Permissions and Audit Settings for File System

Permissions and Audit Settings for Registry

Permissions and Audit Settings for Printers

Permissions and Audit Settings for Shares

Special Permissions and Audit Settings

Ownership

Copyright/License/Warranty Disclaimer

Registration

Security notes

Biggest PC security hole?

A useful programming technique


Overview of DumpAcl
Overview

Somar DumpAcl is a program for Microsoft® Windows NT (TM) that will dump the permissions (DACLs) and audit settings (SACLs) for the file system, registry, printers and shares in a concise, readable listbox format, so that holes in system security are readily apparent. Somar DumpAcl also dumps user and group information. Somar DumpAcl is a must-have product for Windows NT systems administrators.

Windows NT contains the mechanisms for providing strong system security, using permissions to control access to files, registry keys, printers, shares and other securable items and auditing to log successful and failed access attempts. However, it can be very difficult to determine if permissions and audit settings have been set correctly, since there are so many files and registry keys on the typical system. The situation is analogous to having a building with unbreakable locks on each of 10,000 doors. The problem is not with the locks themselves, but rather with one person walking around on a regular basis and checking that none of the 10,000 doors is unlocked.

Somar DumpAcl provides a solution to the problem of too many files and registry keys to check on a regular basis, by producing a concise and readable report of permissions and audit settings. By reviewing this report, you can determine if users have more access to the file system, registry or printers than you want to allow. You can then use file manager, registry editor or print manager to set permissions differently.

Some users have suggested just setting permissions on the root directory or registry key (e.g. C:\ or HKEY_LOCAL_MACHINE) and letting those permissions be propagated to all child directories/files/keys. In general, however, it is not acceptable for all directories, files and/or registry keys to have the same permissions. In fact, trying to make all permissions the same may prevent Windows NT from running properly.

See Security notes for further general discussion of computer security.


Installation

1) Place DUMPACL.EXE and DUMPACL.HLP together in any directory.

2) The first time DUMPACL.EXE is run, it will create the following registry key:

HKEY_CURRENT_USER\SOFTWARE\SomarSoftware\DumpAcl

3) Somar DumpAcl makes no other changes to your system.


Uninstallation

1) Run DUMPACL.EXE with /u as a command line parameter. If successful, a message box will be displayed indicating that the SomarSoftware\DumpAcl registry key has been deleted.

2) Delete DUMPACL.EXE and DUMPACL.HLP from your computer.


Known bugs and limitations
Known bugs, limitations and planned enhancements

1) Somar DumpAcl currently does not support Unicode. Somar DumpAcl will be Unicode enabled in a future release.

2) Somar DumpAcl does not indicate whether directory permissions are inheritable. File manager always makes directory permissions inheritable so this is not a severe limitation. That is, of the permissions in the list below, type (b) is always the same as (a), if you used File Manager to set file system permissions:

a) Permission applies to directory itself (Dir column of Somar DumpAcl report)

b) Permission will be inherited by newly created subdirectories in directory (not shown by Somar DumpAcl)

c) Permission will be inherited by newly created files in directory (File column of Somar DumpAcl report)

3) The WIN32 SDK is not clear as to the interpretation of printer access masks and so there are likely bugs in the Somar DumpAcl report for printers. This issue is being worked.

4) The print setup settings (Portrait/Landscape Orientation, selected printer, etc) are not saved as part of a users profile. This feature may be added in the future.

5) Security Policy information (including: Account, User Rights and Audit Policies, and Trust Relationships) is not dumped. Microsoft has not yet provided the programming documentation necessary to dump this data. As a workaround, you can do the following:

a) Display information using User Manager.

b) Print active window (User Manager dialog) to clipboard using ALT-PrintScrn.

c) Paste from clipboard into Windows Paintbrush.

d) Print from Windows Paintbrush (partial page option usually works best).

6) Replication information is not dumped. This may be added in a future release.

7) There are categories of securable items besides those currently dumped or mentioned above. Some of these categories may be added in the future. User suggestions are welcome.


Permissions and Audit Settings for File System Entries

If the Grouping Enabled option is selected, Somar DumpAcl shows as little of the file system as possible. Permissions for a subdirectory are the same as for the parent directory, unless the permissions for the subdirectory are explictly shown. Permissions for all files in a directory are the same as the permissions in the file column of the directory, unless the permissions for the file are explictly shown. The CREATOR OWNER account is ignored in comparisons of permissions, since this pseudo-account is converted to the account of the user who creates a file in a directory.

Dir column (used for directories only)

R	Account can list the contents of the directory.
W	Account can add new files and subdirectories to the directory.
X	Account can traverse the directory as part of a path.
D	Account can delete the entire directory.
P	Account can change permissions for the directory and all files and subdirectories.
O	Account can take ownership of the directory.
All	Same as RWXDPO.
No access	Account is denied all access to directory.

File column (used for directories and files)

For files, this column lists the permissions that apply to the file. For directories, this column lists permissions that will be inherited by files created in the directory, unless the creator of the file explicitly specifies other permissions.

R	Account can read the file.
W	Account can write to the file.
X	Account can execute the file.
D	Account can delete the file.
P	Account can change permissions for the file.
O	Account can take ownership of the file.
All	Same as RWXDPO.
No access	Account is denied all access to file.

Audit settings

R	Audit attempts to read file or list directory contents.
W	Audit attempts to write to file or add files/subdirectories to directory.
X	Audit attempts to execute file or traverse directory as part of a path.
D	Audit attempts to delete file or directory.
P	Audit attempts to change change permissions for the file or directory.
O	Audit attempts to take ownership of the file or directory.
All	Same as RWXDPO audit settings.

See also Special Permissions and Audit Settings.

Example and interpretation:

Path	Account         Own Dir        File    Success   Failure

c:\MYDIR1\	Administrators   o  All        All

c:\MYDIR1\	Everyone            R X        R X

c:\MYDIR1\	CREATOR OWNER                  All

c:\MYDIR1\	SYSTEM              All        All

c:\MYDIR1\MyDir2\MyFile1.txt	Administrators   o             All

c:\MYDIR1\MyDir2\MyFile1.txt	Everyone                       RWXD              all

c:\MYDIR1\MyDir2\MyFile1.txt	SYSTEM                         All

All directories and files under C:\MYDIR1\ have the same permissions as listed for C:\MYDIR1\, except for file C:\MYDIR1\MyDir2\MyFile1.txt. Administrators is owner of these directories and files. Also, failed attempts by anyone to access (read, write, delete, execute, change permissions or take ownership) the C:\MYDIR1\MyDir2\MyFile1.txt file are audited.


Permissions and Audit Settings for Registry Keys

Only the HKEY_LOCAL_MACHINE and HKEY_USERS hives can be dumped if a remote computer is specified.

Unless the Show All option is selected on the View menu, Somar DumpAcl shows as little of the registry hive possible. Permissions for a subkey are the same as for the parent key, unless the permissions for the subkey are explictly shown. The Key column shows the permissions for the key itself. The Inheritable column shows the permissions that will be inherited by new subkeys created under the key, unless the creator of the subkey explictly specifies other permissions.

Permissions

Q	Account can query values for the key.
S	Account can create or set values for the key.
C	Account can create sub keys under the key.
E	Account can enumerate sub keys under the key.
N	Account can request notification whenever the key changes.
L	Account can create a registry link.
D	Account can delete the key.
P	Account can change permissions for the key.
O	Account can change the key owner.
R	Account can read the permissions for the key.
Read	Same as QENR permissions.
All	Same as QSCENLDPOR permissions.
No access	Account is denied all access to key.

Audit Settings

Q	Audit attempts to query values for the key.
S	Audit attempts to create or set values for the key.
C	Audit attempts to create sub keys under the key.
E	Audit attempts to enumerate sub keys under the key.
N	Audit attempts to request notification whenever the key changes.
L	Audit attempts to create a registry link.
D	Audit attempts to delete the key.
P	Audit attempts to change permissions for the key.
O	Audit attempts to change the key owner.
R	Audit attempts to read the permissions for the key.
Read	Same as QENR audit settings.
All	Same as QSCENLDPOR audit settings.

See also Special Permissions and Audit Settings.

Example and interpretation:

Path                    Account         Own Key        Inheritable  Success   Failure

HKEY_CURRENT_USER       SYSTEM              All        All

HKEY_CURRENT_USER       Administrators   o  All        All

HKEY_CURRENT_USER       Frank               All        All

HKEY_CURRENT_USER\Junk  Administrators   o  All        All

HKEY_CURRENT_USER\Junk  SYSTEM              All        All

HKEY_CURRENT_USER       Everyone                                                  DP

All keys under HKEY_CURRENT_USER have the same permissions as listed for HKEY_CURRENT_USER except for the HKEY_CURRENT_USER\Junk key and its subkeys. Administrator is owner of these keys. Also, failed attempts by any user to delete or change permissions for the HKEY_CURRENT_USER\Junk key are audited.


Permissions and Audit Settings for Printers

Permissions

PrintOnly	Account can print to the printer.
ManageDocs	Account can delete or pause documents for the printer. If this permission is granted to the CREATOR OWNER pseudo-account, then users have permission to manage their own print documents. Users can manage the documents of other users only if they are members of a group other than CREATOR OWNER which has the ManageDocs permission for the printer.
All	Account can print to the printer, manage documents, delete the printer, change permissions for the printer, and take ownership of the printer.
No access	Account is denied all access to printer.

Audit Settings

P	Audit attempt to print.
F	Audit attempt to perform full control operation (the Windows NT documentation gives no indication as to what this means).
D	Audit attempt to delete printer.
C	Audit attempt to change permissions.
O	Audit attempt to take ownership.
All	Same as PFDCO audit settings.

See also Special Permissions and Audit Settings.

Example and interpretation:

Printer                 Account         Own Permission  Success   Failure

Laser                   CREATOR OWNER       ManageDocs

Laser                   Administrators   o  All

Laser                   Everyone            Print                 All

Laser                   Power Users         ManageDocs

All users can print to the printer named Laser, and can manage the documents they print. Power Users can print and manage the documents of other users. Administrators can perform all printer functions, including deleting the printer and changing permissions and ownership. Administrators is owner of the printer. Failed attempts by any user to access the printer (print, manage documents, delete, change permissions or take ownership) are audited.


Permissions and Audit Settings for Shares
Permissions for Shares

Shares do not have an owner or audit settings. Some shares do not have DACL

Permissions for file shares

Read	Account can read the shared directory and it subdirectories and files.
Change	Account can read and write the shared directory and it subdirectories and files, including adding and deleting subdirectories and files.
All	Account can read, write, change permissions on and take ownership of the shared directory and it subdirectories and files.
No access	Account is denied all access to shared directory and its subdiretories and files

See also Special Permissions and Audit Settings.

Example:

Path	Account	Permission
C$=C:\		==>No DACL
C_DRIVE=C:\	Administrators	All
temp=C:\temp	Group1	No access
temp=C:\temp	Group2	Change
temp=C:\temp	Everyone	Read


Special Permissions and Audit Settings

Axhhhhhhh	Non-standard allow permissions or audit settings, see WIN32 SDK documentation.
Dxhhhhhhh	Non-standard deny permissions, see WIN32 SDK documentation.
==>access denied	User who is executing Somar DumpAcl cannot read the permissions or audit settings.
==>no DACL	No DACL was found. Normal system ACL editors (such as file manager, registry editor and print manger) never allows no DACL, but other ACL editors might. No DACL is normal for administrative shares (ending with $).
==>empty DACL	Empty DACL was found, which is equivalent to all permission for Everyone. Normal system ACL editors (such as file manager, registry editor and print manger) never allows no DACL, but other ACL editors might.


Ownership

The owner of a securable item is indicated by an o in the Own column when the Show Owner option is selected. Shares do not have an owner.

When Enable Grouping is selected, Somar DumpAcl takes ownership into consideration in attemping to group items. Two items with the same permissions but different owners are grouped provided the owners have explicit permission to change permissions or take ownership of their respectively owned item (i.e. other than as a consequence of being the owner). Otherwise, the items are not grouped.

Example and interpretation:

(grouping disabled, or grouping enabled and John and Mary NOT both members of Managers group):

Path	Account         Own Dir        File

c:\Dir\	John             o

c:\Dir\	Managers            All        All

c:\Dir\File 	Mary             o

c:\Dir\File	Managers            All        All

(grouping enabled and John and Mary both members of Managers group):

Path	Account         Own Dir        File

c:\Dir\	John             o

c:\Dir\	Managers            All        All

(i.e. c:\Dir\File not shown because it was grouped with its parent directory).

In this example, permissions are the same for the file and directory, but ownership differs. If John and Mary are members of the Managers group, then John can take ownership and change permissions on the c:\Dir\ directory and Mary can take ownership and change permissions on the c:\Dir\File file (because All permission allows taking ownership). Therefore, Somar DumpAcl groups the file and directory.

Ownership is important because the owner of an item can always set permissions for that item. If Mary were not a member of the Manager group, she could still change permissions on the c:\Dir\File file at any time, and thereby obtain access to information that someone thought was only available to Managers. Likewise, if John were not a member of the Manager group, he could still change permissions on the c:\Dir\ directory at any time to give himself full control (via inheritance) of newly created files in this directory, that one might think (if looking only at the permissions on the directory) would only be available to Managers.


Copyright/license/warranty
Copyright/License/Warranty Disclaimer

Somar DumpAcl (TM) is Copyright © 1994 Somar Software, All rights reserved.

Send problem reports and other comments to 72202.2574@compuserve.com.

License Agreement and Warranty Disclaimer

You should carefully read the following terms and conditions before using this software.  Use of this software indicates your acceptance of these terms and conditions.  If you do not agree with them, do not use the software.

Shareware Version

You are hereby licensed to: use the Shareware Version of the software for a 21 day evaluation period; make as many copies of the Shareware version of this software and documentation as you wish; give exact copies of the original Shareware version to anyone; and distribute the Shareware version of the software and documentation in its unmodified form via electronic means. There is no charge for any of the above.

You are specifically prohibited from charging, or requesting donations, for any such copies, however made; and from distributing the software and/or documentation with other products (commercial or otherwise) without prior written permission, with one exception: Disk Vendors approved by the Association of Shareware Professionals are permitted to redistribute Somar DumpAcl, subject to the conditions in this license, without specific written permission.

You are specifically prohibited from copying or redistributing the keyfile (DUMPACL.KEY) that will be sent to you upon receipt of your registration payment.

Unregistered use of Somar DumpAcl after the 21-day evaluation period is in violation of United States and International copyright laws.

For how to register, see Registration.

A single registered copy of Somar DumpAcl can only be installed on a single computer. Thus, if you have 3 computers on which you want to install Somar DumpAcl, you must register and pay for 3 copies of Somar DumpAcl.

Governing Law

This agreement shall be governed by the laws of the District of Columbia.

Disclaimer of Warranty

THIS SOFTWARE AND THE ACCOMPANYING FILES ARE SOLD "AS IS" AND WITHOUT WARRANTIES AS TO PERFORMANCE OF MERCHANTABILITY OR ANY OTHER WARRANTIES WHETHER EXPRESSED OR IMPLIED. BECAUSE OF THE VARYING HARDWARE/SOFTWARE ENVIRONMENTS INTO WHICH SOMAR DUMPACL MAY BE PUT, THERE IS NO WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE.

GOOD DATA PROCESSING PROCEDURE DICTATES THAT ANY PROGRAM BE THOROUGHLY TESTED BEFORE RELYING ON IT. THE USER MUST ASSUME THE ENTIRE RISK OF USING THE PROGRAM. ANY LIABILITY OF THE SELLER WILL BE LIMITED EXCLUSIVELY TO PRODUCT REPLACEMENT OR REFUND OF PURCHASE PRICE.


Registration

This is not free software. This license allows you to use this software for evaluation purposes without charge for a period of 21 days.  If you use this software after the 21 day evaluation period a registration fee of $49 is required. Payments must be in US dollars drawn on a US bank,  payable to Somar Software, and sent to Somar Software, 1 Scott Circle, NW Suite 816, Washington, DC 20036, USA. You can also register through CompuServe (GO SWREG, ID 2723).

Upon receipt of your registration payment (check or CompuServe notice), you will be sent a key file (DUMPACL.KEY), which is to be placed in the same directory as DUMPACL.EXE. This key file will be your proof of registration. The presence of this key file will enable certain functions of Somar DumpAcl which are disabled in the unregistered version. These functions involve the ability to produce hardcopy printouts of the Somar DumpAcl report.

Somar Software reserves the right to increase the registration fee at any time without notice. If the fee has been increased, and your payment is received after such increase, then Somar Software has the right to require additional payment before accepting your registration and sending you a key file. Once you have paid the then current registration fee, and Somar Software has accepted your fee and sent you a key file, you have the right to use the version of Somar DumpAcl that you paid for, for as long as you want, without additional payment. Future versions of Somar DumpAcl may require a different key file. You may be required to pay an additional fee to upgrade to such future versions.

A single registered copy of Somar DumpAcl can only be installed on a single computer. Thus, if you have 3 computers on which you want to install Somar DumpAcl, you must register and pay for 3 copies of Somar DumpAcl.

You may access the registered version of Somar DumpAcl through a network, provided you have obtained individual licenses for the sotware covering all workstations that will access the software through the network.


Security notes

What is security?

A secure system is one that is protected against various natural disasters and human attacks. Security with respect to a computer system is very similar to security with respect to a bank vault. A computer system or bank vault containing valuables (data in the case of a computer system, secret documents or jewels in the case of bank vault) is secure if:

1) No one can look at, modify or remove any of the valuables for which they do not have the proper authority. In the computer context, this requires:

Permissions are set properly.

Computer is physically secured, possibly inside a locked room.

Data is encrypted if computer cannot be physically secured (e.g. portable PC).

Backup tapes are physically secured in a safe, or else encrypted.

There are procedures in place to ensure viruses do not get introduced into the system.

2) No person or natural disaster such as a fire can easily destroy the valuables. In the computer context, this requires:

Permissions are set properly.

Backups are performed regularly.

Copies of backup tapes are stored offsite.

There are procedures in place to ensure viruses do not get introduced into the system.

3) No one can easily disrupt authorized access to the valuables. In the computer context, this requires:

Permissions are set properly.

There are procedures in place to ensure viruses do not get introduced into the system.

An example of disrupting authorized use of a computer system is a virus that modifies and thereby corrupts the registry so a database program will not run. The database itself maybe intact (because it was protected by permissions), but the data cannot be accessed until the registry is repaired, which may require reinstalling the database program. This temporary disruption can be as costly as actual loss of data for many mission critical computer systems.

Note the importance of permissions and viruses, which are implicated in all types of security risks. Permissions are the primary protection against malicious users and viruses which run under user accounts. There is no way to protect against viruses which run under administrator or system accounts. So it is very important to avoid running untrusted programs when logged on as an administrator, or to allow untrusted program to be run as services under a system or administrator account.

What should a well-organized set of permissions look like?

A well-organized set of permissions will produce a short Somar DumpAcl report. In general, the shorter the report produced by Somar DumpAcl, the easier to understand, and so the more confident the systems administrator will be that permissions have been set properly.

Issue of registry key permissions

Use Somar DumpAcl to produce a report of the HKEY_LOCAL_MACHINE registry hive. Note that Everyone has write and delete access to many keys. So any user who can access the registry locally or remotely can make changes that might disrupt system operations (type 3 security breach, as described above) and possibly obtain unauthorized access to files (type 1 and 2 security breach). Neither I nor anyone I have discussed this issue with seems to understand the registry well enough to definitely state what the potential for mischief is in allowing Everyone have write access to so many registry keys. No one seems to know whether this access can be taken away, or whether doing so will cause problems with the normal operation of Windows NT. The registry key permissions seem to have been set in a very haphazard and inconsistent way.


Hole in security
Biggest PC security hole?

If you open a document which is set up to run an embedded macro or script upon opening (Microsoft Word, among other programs, can produce such documents), you are in effect running a program. The macro which is embedded in the document and which runs when the document is opened, could cause the same damage to your system as a virus embedded in a .EXE program. If you download an arbitrary document from a BBS and open it, you are exposing yourself to the same risk of a virus infection as when you download a .EXE program from a BBS and run it.

Organizations which are concerned about viruses should require that documents be transferred and downloaded from untrusted sources only in formats which do not provide for embedded macros. These organizations should also require vendors whose programs can produce documents with embedded macros to provide an option to disable these macros. Your organization should then require all users to set this option. It should also be possible to install the program so that the option can never be reset.

Authors who need to create documents which have associated programs (such as a legal document template with associated dialog box containing entry boxes and pick lists), should create two files: a .EXE file which contains the program and a document file for the document itself. It is possible, using OLE automation and Visual Basic or similar mechanisms, to do almost anything with these external scripting languages that can be done with embedded scripting languages and macros. The reason it is safer to produce separate .EXE files to contain program logic, is that users can be trained to regard .EXE files from untrusted sources with suspicion, while it would be very confusing to explain to ordinary users why it is dangerous to merely open a document.

Note that this security hole is not specific to Windows NT, and in fact Windows NT is better secured against viruses of any sort than most other PC operating systems.


Programming technique
A useful programming technique

Suppose you are writing an application that will store data in files. You only want users to access the files through your program, and not to be able to access the files directly.

One approach is to use a client server design, where the user executes a client program which communicates via RPC or other methods with a server program running as a service under a privileged account. The permissions on the files can be set so that only the privileged account has access.

Another approach is as follows. Create a special directory with permissions set such that only privileged accounts can list the contents of the directory. Put the files in the directory with permissions set such that all users can access the files. For example:

\dir\	(full control for priviliged accounts)

\dir\file	(full control for all accounts)

Users will not be able to access the files using file manager, the command prompt or the file open dialog of applications, because they lack list permission for the directory. However, programs running under the account of the user will be able to access the file, provided the program specifies the entire program path during the open and provided the user has the Bypass Traverse Checking user right.

The Bypass Traverse Checking right is granted by default to all users. It can be reset using User Manager. When a user has this right, NT only checks the permissions on the file being opened, and not the permissions on the directories which make up the file path. This behavior differs from that of Unix, which requires list access on all directories which make up the file path.

User who know how to write programs themselves can, of course, defeat this simple security technique, so it is not a substitute for true client-server design for situations which require strong security.